Product documentation
Setup & Configuration describes how to configure HSO Service Management for operational service delivery, contract management, planned maintenance and financial processing. The configuration should follow a controlled sequence because Service Objects, Event Codes, Call Types, Service Level Definitions and Project Integration depend on shared master data and settings in Microsoft Dynamics 365 for Finance and Operations.
Introduction
A successful Service Management implementation requires coordination between service operations, project accounting, finance, inventory, resource planning and contract management. The configuration should reflect the organization's actual service processes and commercial agreements rather than relying on system defaults without validation.
Recommended configuration sequence
Configure Service Management in the following order:
Service Management Parameters and Number Sequences.
Service Objects, Object Types, Component Types and object structures.
Event Codes, Service BOMs and Service Operations.
Call Types, Call Statuses, SLA rules and diagnostic codes.
Coverage Types, Contract Types, Service Level Definitions and Contract Templates.
Project Integration, pricing and financial defaults.
Service Schedules, planned maintenance and reporting categories.
Integration-specific settings and end-to-end validation.
Some configuration activities overlap. In particular, Project Integration should be designed together with Call Types and Service Level Definitions because these settings collectively determine transaction posting and invoicing.
Configuration principles
Use meaningful codes and descriptions, establish consistent naming conventions and document the intended behavior of each configuration record. Avoid creating unnecessary variations of Call Types, Event Codes or Object Types when existing definitions can support the required process. Financial configuration should distinguish genuinely different posting and billing scenarios, even when this results in several Project Integration IDs.
End-to-end validation
Configuration should be tested through complete service scenarios rather than by checking individual setup forms. At minimum, validate reactive service, warranty, contract coverage, planned maintenance, task execution, financial posting and invoicing. Where applicable, include Mobile Field Service, graphical planning and Repair Centre processing.
Introduction
Service Management Parameters establish the module-wide defaults and integration settings used throughout HSO Service Management. The parameter form includes General, Service Object, Service Call, Project Integration, Hours as Items, Hours via Revenue, Workshop Locations, Colours, Advanced Search and Number Sequences.
Number Sequences
Configure Number Sequences before creating operational records. Sequences are required for entities such as Service Objects, components, Service Calls, Service Contracts, Coverage Types and Service Level Definitions. For configuration entities where meaningful codes are preferred, manual numbering can be appropriate. Examples include Object Types, Event Codes, operation numbers, SLD IDs, Contract Template IDs and Coverage Types.
General parameters
General parameters define shared behavior such as object selection, time entry methods, travel and visit cost defaults, contract renewal behavior and coverage pricing defaults. These settings should be agreed with the relevant service and financial stakeholders before transactional testing.
Service Object parameters
Service Object parameters determine default behavior for Service Objects, including the invoice project, status handling, work order Call Type and warranty defaults. The configuration should reflect how equipment is identified, maintained and linked to customer service processes.
Service Call parameters
Service Call parameters define defaults for Call Type processing, Project Integration, sales order or item requirement handling, warranty assignment and the call timer. The default Service Level Definition is particularly important because it determines the operational and financial rules for service work that is not covered by a Service Contract.
Project Integration parameters
These parameters provide the fallback financial configuration, including the sub-project numbering mask, project group, default Project Categories, journals and accounts for the supported transaction types. More specific Project Integration rules are subsequently selected through the applicable SLD.
Additional parameters
Hours as Items and Hours via Revenue contain settings for alternative labor billing methods. Workshop Locations identify the warehouses used for Repair Centre processing, while Colours and Advanced Search provide presentation and search-related configuration.
Introduction
Service Object configuration determines how equipment is identified, classified and maintained. The Object Type is a central design element because it controls which Event Codes, Service Operations, maintenance schedules and other object-specific functionality are applicable.
Object Types
Define Object Types according to meaningful differences in service behavior rather than creating a separate type for every product. Objects of the same type should generally share the same applicable Event Codes, maintenance activities, component structure and operational rules. Where different service processes are required, separate Object Types may be appropriate.
Component Types
Component Types classify the components associated with Service Objects. They provide structure for component registration, Service Operations, measurements and counter readouts. Configure the component types required for the intended equipment models and service activities.
Object hierarchy
Service Objects can be organized into parent-child relationships to represent equipment assemblies, installations or other structured assets. The hierarchy should reflect the level at which the organization registers service history, contracts and maintenance obligations.
Object templates
Object Templates and Multi-Level Object Templates can standardize the creation of Service Objects and their component structures. Configure reusable templates for equipment types with consistent structures to reduce manual entry and maintain data quality.
Warranty setup
Warranty configuration defines the applicable warranty periods and related Service Object defaults. Warranty processing also depends on the configured Call Types, Service Level Definitions and Project Integration. Test warranty identification, assignment and financial processing together to ensure that covered work receives the intended treatment.
Introduction
Event Codes define the service activities that can be performed on Service Objects. Combined with the Object Type, an Event Code determines the applicable work package and provides the operational defaults used when creating Service Tasks.
Event Codes
Create Event Codes for recognizable service activities, such as inspection, repair, calibration, installation or replacement. Event Codes must be linked to the relevant Object Types before they can be selected for those Service Objects.
Work packages
The Object Type and Event Code combination can define estimated labor, item requirements, travel, revenue, Service Operations and Resource Requirements. This configuration allows Service Tasks to be created with the expected work already available for planning and execution.
Service BOM
The Service BOM defines the materials expected for a particular service activity. Configure the applicable items and quantities according to the work normally required. These lines provide the starting point for the Service Task forecast and can be adjusted when the actual service requirements differ.
Service Operations
Service Operations describe the activities and results that must be recorded during execution. Supported operation types include Check, Measure, Counter Readout, Calibrate, Exchange and Operation. Configure the required operation definitions and link them to the appropriate Event Code and Object Type combinations.
Resource Requirements
Resource Requirements identify the capabilities or qualifications required to perform a Service Task. These requirements support resource selection and scheduling. The detailed configuration of the graphical planning functionality is maintained in the separate Planning & Scheduling documentation.
Introduction
Service Call configuration determines how customer requests are classified, processed and monitored. Call Types, Call Statuses, SLA rules and diagnostic codes collectively establish the operational workflow.
Call Types
Call Types represent different service processes, such as breakdown service, warranty, planned maintenance or other defined activities. Configure Call Types according to meaningful differences in workflow, SLA commitments or financial treatment.
Call Statuses
Call Statuses define the stages through which a Service Call progresses. For each status, establish its operational purpose, responsible role, permitted transitions, closure behavior and any mandatory information. Call Status configuration can also control automatic updates based on Service Task progress and other service events.
Service Level Agreements
SLA rules determine action times and deadlines for Service Calls. Default timings can be configured on Call Type status lines, while Call Type SLA records allow more specific rules based on priorities, severities, contracts, Contract Types, Object Types or individual Service Objects.
SLA calendars and reference dates
SLA calculations depend on calendars, reference dates and time zones. Define whether action times are calculated from the SLA reference time, from a status change or backward from a deadline. Test working-time calendars, 24-hour calendars, high-priority calls and out-of-hours scenarios to confirm that deadlines are calculated as intended.
Complaint, Cause & Solution Codes
Complaint, Cause and Solution Codes support consistent issue classification and reporting. Configure meaningful reusable codes and determine where they must be entered. Mandatory code requirements can be associated with Call Type statuses and closure conditions.
Diagnostic Trees
Diagnostic Trees restrict the available Complaint, Cause and Solution Codes according to the Object Type. Configure the tree structure, link the applicable codes and assign the tree to the relevant Object Types. When no Diagnostic Tree is assigned, the complete code lists remain available.
Introduction
Service Contract configuration combines commercial agreements with operational service rules. Coverage Types, Contract Types, Service Level Definitions and Contract Templates should be configured before creating production Contract Proposals.
Coverage Types
Coverage Types define the services and entitlements included in an agreement, such as covered labor, materials, travel, inspections or preventive maintenance. Use descriptions that clearly identify what is covered rather than generic labels that may be interpreted differently by users.
Contract Types
Contract Types define the commercial model and invoicing behavior. Configure the applicable periodic invoicing, prepayment, frequency schedules, interval schedules, usage counters and depreciation options. Maximum coverage lines determine which Coverage Types can be used and how the associated coverage prices are calculated.
Service Level Definitions
An SLD combines allowed Call Types, the default Call Type, Coverage Type and Project Integration for selected object scopes. Rules can apply to all Service Objects, an Object Group or an individual Service Object. The Block not listed Call Types option restricts selection to the Call Types explicitly defined in the SLD.
Default and contracted SLDs
The default SLD determines the service rules for work outside a Service Contract, while a contracted SLD establishes the conditions applicable to covered Service Objects. Because SLD selection influences both workflow and financial processing, changes to an SLD already used by active contracts should be carefully assessed.
Contract Templates
Contract Templates provide reusable defaults for Contract Proposals, including Contract Type, SLD, duration, Invoice Group, revenue period, Visit Tariff, coverage specification and cancellation settings. Templates should represent recognizable commercial offerings and reduce differences between proposals created by different users.
Contract Trade Agreements
Contract Trade Agreements define item prices or discounts for a specific contract, contract group or broader contract selection. Configure these agreements when customers require prices that differ from standard sales pricing, and validate the resulting prices through a Service Task created under the relevant contract.
Introduction
Project Integration is a central element of Service Management configuration because it determines how service transactions are validated, posted and invoiced through Project Management and Accounting. The applicable Project Integration ID is selected through the Service Level Definition based on the Service Call context.
Project Integration IDs
Create separate Project Integration IDs for financial scenarios that require different posting or invoicing behavior. Typical examples include time-and-material service, warranty, covered contract work, prepayment and fixed-fee service. Different transaction tariffs or category restrictions can also justify separate configurations.
Transaction defaults
For each Project Integration ID, configure the relevant defaults for Hours, Items, Costs, Travel, Revenue and Depreciation. These settings include Project Categories, Line Properties, Invoice Status, journals and posting behavior. The configuration must be consistent with the project groups, accounts and financial setup in Microsoft Dynamics 365 for Finance and Operations.
Selection and validation rules
Project Integration selection rules determine which Project Categories and Line Properties are permitted and how transactions that differ from the defaults are evaluated. Configure these rules to support the intended chargeability model and prevent inappropriate combinations from being selected during Service Task registration.
Financial decision chain
The financial treatment of a Service Call is determined through the relationship between its Call Type, applicable SLD and Project Integration. The Project Integration then supplies the Project Category, Line Property and Invoice Status used for the relevant transaction. This relationship must be tested for each significant business scenario, particularly where contract coverage, warranty or non-chargeable work is involved.
Coverage and contract pricing
Configure coverage prices according to the commercial structure defined by the Contract Types and Coverage Types. Where applicable, use price groups, discounts and Contract Trade Agreements to establish customer-specific or contract-specific prices.
Task revenue and transaction text
Revenue settings can define fixed service fees or other charges generated through the Service Task work package. Transaction text configuration determines how the resulting financial transactions are described, including their presentation during invoice preparation.
Visit Tariffs
Visit Tariffs define travel charges for service visits. A tariff can include a fixed visit price, a price per distance unit and a price per travel hour. Tariffs can default from the Service Contract or Service Object, with the Service Object tariff able to override the contract tariff during task completion.
Hours as Items
Hours as Items supports the conversion of registered working time into item-based transactions according to configured conversion rules. Configure the relevant relationships and verify how quantities, prices and financial transactions are processed.
Hours via Revenue
Hours via Revenue supports billing registered labor through Revenue transactions rather than directly through the original hour transaction. Configure the applicable Hour Category to Revenue Category relationships and any required rounding or rate rules. This method requires careful validation of both the original labor cost and the resulting invoiceable revenue to prevent incorrect or duplicate invoicing.
Pricing validation
For each billing model, create representative Service Calls and Service Tasks and verify the resulting forecasts, actual project transactions and invoice proposals. Include standard time-and-material work, covered service, warranty, fixed fees, travel charges, prepayments and alternative labor billing methods where applicable.
Introduction
The remaining configuration covers planned maintenance schedules, reporting categories and integration-specific functionality. These settings should be completed after the relevant Service Objects, Event Codes, contracts and financial structures have been established.
Service Schedules
Service Schedules determine how maintenance activities are planned. Configure Manual, Frequency or Interval schedules according to the required maintenance process, link them to the appropriate Object Types and define the applicable Event Codes and scheduling rules.
Planned Maintenance
Validate the complete maintenance process by creating a Service Schedule, linking it to the relevant Object Types, adding it to a Contract Proposal and generating the visit forecast. Confirm that the resulting Visit IDs contain the expected dates, Event Codes and Service Objects. For meter-driven maintenance, include meter readings and forecast recalculation in the test.
Cockpit Categories
Cockpit Categories group Project Categories into meaningful reporting classifications. Configure amount and hour categories for areas such as labor, materials, travel, warranty, contract revenue and other service costs. These groupings should correspond to the financial reporting structure to avoid discrepancies between the Service Management Cockpit and project accounting.
Planning & Scheduling
Service-specific Resource Requirements and task scheduling are configured in conjunction with the shared graphical Planning & Scheduling functionality. General planning board configuration, Scheduling Groups and resource scheduling are documented separately in the Graphical Planning & Scheduling product documentation.
Repair Centre
Repair Centre requires workshop warehouse settings, repair items on Object Types and workshop repair Event Codes. These settings support the receipt, processing and return of customer equipment. Detailed Repair Centre configuration and its workshop scenarios are maintained in the separate Repair Centre documentation.
Final configuration validation
Before operational use, complete an end-to-end test of the configured processes. Confirm that Service Objects can be created, Service Calls receive the intended SLD and Project Integration, Event Codes generate the correct work packages, Service Tasks can be executed and realized, and financial transactions produce the expected invoices. Contract proposals, planned maintenance, warranty handling and applicable integrations should be included in the validation.